@productdevbook is attempting to deploy a commit to the maximogarciamartinez's projects Team on Vercel.

A member of the Team first needs to authorize it.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
nuxt-better-auth-docs	Error		Jan 27, 2026 6:01am

@onmax I just added this. better-auth:client:extend

Hey @productdevbook, nice work on this PR. Just checked, and I like the direction :). could you split out everything not directly tied to Nitro v3 compatibility? I’d keep this PR focused on the nitro/* import changes + getRouteRules/request handling updates.

Move to separate PR:

• better-auth:client:extend feature (hooks types + module hook + defineClientAuth/useUserSession changes)
• .nuxtrc
• auth.config.ts + server/auth.config.ts (if just examples)

If you’d rather, I can extract these into a separate PR.

It would be good if you could separate them because I'll be away from nuxt for 2-3 months.

When closing, it is beneficial to state your thoughts here. The reason for closing should not remain with you. :)

Sorry, I miss clicked. I didn't mean to close this pr. You are right :)

Hi @productdevbook, I wanted to share a parallel architecture idea I’ve been playing with and get your thoughts on it.

I opened #281 as a draft spike to explore a different direction for Nitro v3 support:

• keep a single package
• keep . and ./config Nuxt-first
• add dedicated Nitro entry points like ./nitro and ./nitro/config
• keep the Nitro v3 work isolated for now, without refactoring the Nuxt entry to consume it yet

The main goal is to move toward a more layered architecture: establish a Nitro-first server layer first, then later make the Nuxt module consume that layer internally.

This is not meant as “#281 instead of #87”. It’s more of an architectural experiment to validate another shape for the module. Ideally, if this direction makes sense, we would still merge the work through #87 rather than replace it with my draft PR.

I also think this could make it easier to support other Nitro-based frameworks in the future.

I’d also like to know if you’re interested in continuing to develop this direction yourself, or if you’d prefer that I take it over. I don’t want to throw away the work you already did, but I do really like this approach.

If you have any comments on the architecture, tradeoffs, or anything that feels wrong with this direction, I’d really like to hear them before this goes any further.

Thank you!